Direct Memory Access Interface

Table of content

• 1. Introduction
• 2. Signal list
• 3. Protocol
• 3.1 Simple transfer
• 3.2 Transfer with wait states
• 3.3 Multiple transfers
• 3.4 Transfer response
• 3.5 Priority control
• 3.5.1 Data rate control
• 3.5.2 Bootloader case
• 4. ASIC Implementation
• 4.1 Clock domains
• 4.2 DMA wakeup

1. Introduction

The openMSP430 Direct-Memory-Access interface acts as a gateway to the whole logical 64kB memory space and can be enabled be uncommenting the DMA_IF_EN macro in the "openMSP430_defines.sv" file:

//-------------------------------------------------------
// Include/Exclude DMA interface support
//-------------------------------------------------------
`define DMA_IF_EN

It supports the efficient connection of Bootloader, DMA controller, Memory-BIST or any other hardware unit requiring direct read/write access to the CPU memory space.
The interface is also designed as to reuse the existing arbitration logic within the memory-backbone and thus minimize to timing costs of its physical implementation (i.e. no additional muxing layer on an already critical timing path).

An simple system using the DMA interface typically consists of a DMA master directly connected to openMSP430 core:


However, it is also possible to combine different DMA masters using a custom arbitration logic:

2. Signal list

Name	Source	Type	Description
MCLK System clock	openMSP430	System	This clock times all DMA transfers. All signal timings are related to the rising edge of MCLK.
PUC_RST System reset	openMSP430	System	The system reset is active HIGH and is used to reset the sytem, including the DMA master(s).
DMA_WKUP Wakeup	DMA Master (Asynchronous)	System	When HIGH in a Low-Power-Mode, the wakeup signal restores the clocks necessary for the DMA transfer (see ASIC Implementation section).
DMA_ADDR[15:1] Address bus	DMA Master	Address	This is the 15-bit address bus allowing to access the 64kB address space (16b words).
DMA_DIN[15:0] Write data bus	DMA Master	Data	The write data bus is used to transfer data from the DMA master to openMSP430 system during write operations.
DMA_DOUT[15:0] Read data bus	openMSP430	Data	The read data bus is used to transfer data from the openMSP430 system to the DMA master during read operations.
DMA_EN Transfer enable	DMA Master	Control	Indicates that the current DMA transfer is active.
DMA_WE[1:0] Transfer direction	DMA Master	Control	When HIGH, this signal indicates a write transfer on the selected byte, and a read transfer when LOW.
DMA_PRIORITY Transfer priority	DMA Master	Control	When HIGH, this signal indicates a high priority DMA transfer (i.e. CPU is stopped). When LOW, low priority DMA transfer have to wait for the CPU to free the accessed ressource.
DMA_READY Transfer done	openMSP430	Response	When HIGH the DMA_READY signal indicates that a transfer has finished on the bus. This signal may be driven LOW to add wait states to the transfer.
DMA_RESP Transfer response	openMSP430	Response	The transfer response provides additional information on the status of a transfer (OKAY if LOW, ERROR when HIGH).

3. Protocol

3.1 Simple transfer

The following figure shows the simplest transfer, one with no wait states.


In a simple transfer with no wait states:

• The DMA master drives the address, control signals and write data onto the bus after the rising edge of MCLK.
• The openMSP430 ressource (pmem/dmem/peripheral) then samples the address, control and write data information on the next rising edge of the clock.
• For read access, after the openMSP430 ressource has sampled the address and control it can start to drive the read data and this is sampled by the DMA master on the third rising edge of the clock.

3.2 Transfer with wait states

The openMSP430 can insert wait states into any transfer, as shown in the following figure, which extends the transfer by two clock cycles, thus taking additional time for completion.

For both read and write operations the DMA master must hold the address, control and write data stable throughout the extended cycles.

Note: wait states are inserted by the openMSP430 if the CPU is currently busy reading or writing to the same ressource that the DMA controller also wants to access.

3.3 Multiple transfers

The following figure shows three transfers to unrelated addresses, A, B & C.

We can here observe:

• the transfers to addresses A and C are both zero wait state.
• the transfer to address B is one wait state.
• the read data from A is available during the first clock cycle when the address and control B are applied.
• the read data from B is available during the clock cycle when the address and control C are applied.

3.4 Transfer response

The following figure shows two transfers to unrelated addresses, A & B.

We can here observe:

• the transfer to address A returns an ERROR response (note that transfer returning an ERROR response never have wait states).
• the transfer to address B is a regular transfer (i.e. OKAY response) without wait state.

Note: an ERROR response are generated if the transfer address lays between the program and data memories, where nothing is mapped.

3.5 Priority control

3.5.1 Data rate control

The DMA_PRIORITY control signal is available to the DMA master for controlling the application data rate requirements.

• When CLEARED, DMA transfers have a fixed lower priority than the CPU. This means that depending on the exact kind of instructions currently executed by the CPU, the completion time of the DMA transfers cannot be predicted (i.e. DMA transfers are completed only when the CPU is not accessing the trageted ressource).
• When SET, DMA transfers have a fixed higher priority over the CPU. This means that the CPU will will stop execution and give the full bandwidth to the DMA controller. In that scenario, DMA transfers complete in a single clock cycle (i.e. without any wait states), as the targeted ressources are always available (i.e. the CPU is not executing).
• If the application requirements need something in between (namely a minimum DMA transfer data-rate with reduced effect on the firmware exection), then the DMA master can dynamically change the DMA_PRIORITY as required.

These scenario are illustrated in the following figure.

We can here observe:

• phase A illustrates LOW-PRIORITY transfers. Less DMA transfer are completed during that time as shown by the number of wait states.
• phase B illustrates HIGH-PRIORITY transfers. DMA transfers are completed with each clock cycle (i.e. no wait state).
• phase C illustrates MIXED-PRIORITY transfers where the DMA controller is dynamically adjusting the priority to achieve its target minimum data-rate.

3.5.2 Bootloader case

In general, the purpose of a bootloader is to initialize the program memory at startup (i.e after Power-On-Reset).
DMA transfers driven by the bootloader should therefore be performed in HIGH-PRIORITY mode, as the CPU should not start executing instructions on a non-initialized memory.
Once the memory initialization is completed, a reset pulse should be generated by the bootloader to make sure the CPU re-fetches the new RESET vector from the program memory.

A bootloader could be for example be connected as following:

The bootloading sequence is illustrated in the following figure:

4. ASIC Implementation

4.1 Clock domains

If the ASIC low power options are enabled, it is possible to perform DMA accesses when the main CPU is in any Low-Power-Mode (LPMx).
However, in order to avoid unnecessary power consumption while restoring the clocks for the DMA transfer, the MCLK system clock has been split into two clock domains.

• MCLK_CPU : clocks the CPU core itself, namely the frontend and execution logic. When the CPU is in LPMx mode, this clock is ALWAYS OFF, even if a DMA transfer is currently on going.
• MCLK_DMA : clocks the rest of the system (excluding the DBG interface) and gives access to the 64kB memory adddress range to the DMA master. This clock is restored in LPMx modes by asserting the DMA_WKUP pin.

This table summarizes the clock operating modes:

Clock Name	CPU Active	CPU Low-Power-Mode
		DMA_WKUP=0	DMA_WKUP=1
MCLK_CPU	ON	OFF	OFF
MCLK_DMA	ON	OFF	ON

Clock domains are illustrated in the following diagram:

4.2 DMA wakeup

As shown in the "Peripherals" chapter, the Basic-Clock-Module has several control registers giving some flexibility to the firmware as to which clocks are restored when the DMA_WKUP pin is asserted.

Register Name	Address	Bit Field
		7	6	5	4	3	2	1	0
BCSCTL1	0x0057	unused		DIVAx		DMA_SCG1	DMA_SCG0	DMA_OSCOFF	DMA_CPUOFF

• DMA_SCG1    : Restore SMCLK with DMA wakeup
• DMA_SCG0    : Restore DCO oscillator with DMA wakeup
• DMA_OSCOFF : Restore LFXT oscillator with DMA wakeup
• DMA_CPUOFF : Restore MCLK_DMA with DMA wakeup

Note that the DMA_WKUP functionality can be disabled by keeping all these bitfields CLEARED.